Adding support for phone and email #174
Conversation
This is a proposed solution for issue w3c#1 and a counter proposal to PR w3c#65. This change adds support for two new `PaymentOptions` for payer's email and payer's phone number. These values are provided on the `PaymentResponse` object. Since these values should not change the total price, no `PaymentRequestUpdate` event is fired for them. The change also adds a phone number to the `ShippingAddress` data structure with the implication that this gets populated when `requestShipping` is `true`. Here are some variations to this change that should be considered: * Do not include `requestPayerPhone` (issue w3c#1 actually only mentions shipping phone number) * Do include a `requestShippingPhone` value and only populate the `ShippingAddress.phone` value if both `requestShipping` and `requestShippingPhone` are true.
|
One advantage to using boolean types here is that we could change them in the future to be an enum that allowed for required/optional/notRequired values. I'm proposing that we start with boolean to keep it simple and get implementation experience. |
Is the implication that changing from boolean to some other values is a low cost change from an implementation standpoint? Ian |
I'm not implying anything about cost (there are definitely UI challenges for example) but I am implying that it is possible to do this later in a more-or-less backwards compatible way. |
|
This PR LGTM. I'm also okay as a starting point with leaving out "requestPayerPhone" but I do think there are a variety of situations where it would be useful (e.g. hotel bookings, where a shipping address is not requested, but a phone # is). |
|
This sounds fine to me, but I don't understand why you have added phone number to the address, but not email. Neither seems more relevant to the address and I don't think either one has a stronger use case than the one. Can we add both to the address, or create some other Contact structure? |
|
Happy to merge. Will update comment with more detailed outcome later. |
|
Merged as 31346cf after last telcon and further discussion with @mattsaxon. |
This is a proposed solution for issue #1 and a counter proposal to PR
#65.
This change adds support for two new
PaymentOptionsfor payer's emailand payer's phone number. These values are provided on the
PaymentResponseobject. Since these values should not change the totalprice, no
PaymentRequestUpdateevent is fired for them.The change also adds a phone number to the
ShippingAddressdatastructure with the implication that this gets populated when
requestShippingistrue.Here are some variations to this change that should be considered:
requestPayerPhone(issue Should the merchant be able to request your email and recipient phone number #1 actually only mentionsshipping phone number)
requestShippingPhonevalue and only populate theShippingAddress.phonevalue if bothrequestShippingandrequestShippingPhoneare true.